W obecnych czasach obserwuje się lawinowy rozwój sieci komputerowych. Rozwój ten jest szczególnie widoczny w środowisku badawczo-naukowym i akademickim, w którym nie tylko bada się najnowsze technologie, ale także występuje zapotrzebowanie na dużą moc obliczeniową oraz dużą przepustowość sieci. Technologie sieciowe, by sprostać stawianym im wymaganiom, stają się coraz bardziej wyrafinowane a systemy sieciowe - coraz bardziej złożone. Sprawne zarządzanie tak złożoną siecią wymaga szybkiego dostępu do aktualnych informacji o stanie sieci i jej zasobach.

Z myślą o zarządzaniu sieciami komputerowymi opracowany został protokół SNMP, który mimo upływu czasu nadal znakomicie spełnia swoje zadanie. Zawdzięcza to przede wszystkim hierarchicznej strukturze danych oraz elastyczności typu danych. Źródłem danych w modelu zarządzania wykorzystującym SNMP jest każde urządzenie posiadające agenta SNMP. Zakres udostępnianych informacji zależy od implementacji agenta i może obejmować takie parametry jak typy i szybkości interfejsów sieciowych, stan interfejsów sieciowych, liczba przychodzących i wychodzących oktetów i ramek na każdym interfejsie, tablica routingu, wersja oprogramowania obsługująca urządzenie, obciążenie procesora. Zastosowanie SNMP jest jednak ograniczone do aktywnych elementów sieci; użytkownik nie ma także wpływu na zakres udostępnianej informacji. Protokół SNMP, choć doskonale nadaje się do pozyskiwania informacji o stanie sieci, to jednak nie jest odpowiedni do ewidencji zasobów sieci.

Do gromadzenia i przechowywania informacji o zasobach sieci najodpowiedniejsza wydaje się być usługa LDAP, która korzysta z tych samych technik, które przyczyniły się do uniwersalności a przez to i popularności SNMP. Dane w LDAP, podobnie jak informacje agenta SNMP, mają strukturę hierarchiczną.

Celem niniejszego projektu jest opracowanie technik umożliwiających przechowywanie i gromadzenie w bazie LDAP informacji o zasobach POL-34/NASK

2 Założenia ogólne

2.1 Stan obecny

W chwili obecnej krajową sieć komputerową POL34/NASK stanowią 22 jednostki MAN połączone między sobą za pomocą łączy dzierżawionych od Teleinformatyki Kolejowej (lambda asynchroniczna). Zarówno urządzenia sieciowe (routery, switche), jak i pozostałe elementy wyposażenia węzłów, stanowią własność odpowiednich jednostek MAN. Ewidencję elementów każdy MAN prowadzi we własnym zakresie. Nie został opracowany standard dokumentowania, nie ma elektronicznego dostępu do informacji o zasobach.

Obecny stan, ze względu na brak scentralizowanego repozytorium, utrudnia planowanie rozwoju sieci w skali globalnej. Dokładna informacja ułatwia dobór narzędzi koniecznych do wykonania prac w węźle, upraszcza zgłaszanie nieprawidłowości w serwisie, umożliwia szybsze podejmowanie decyzji oraz planowanie rozwiązań awaryjnych. W świetle użytkowania i pielęgnacji sieci optycznej o zasięgu krajowym posiadanie centralnego i standaryzowanego źródła informacji o zasobach sieci komputerowej to nie kwestia wygody, a konieczność.

2.2 Cele ogólne

System ma umożliwić gromadzenie i przeglądanie informacji o zasobach POL-34/NASK. Poprzez zasoby rozumiane są tutaj fizyczne elementy infrastruktury sieci z pominięciem zasobów logicznych, takich jak kanał PVC czy pasmo. Informacje dotyczące konfiguracji logicznej mogą być pozyskiwane poprzez zapytania SNMP. Poza tym konfiguracja logiczna sieci zmienia się znacznie częściej, niż konfiguracja fizyczna, co z kolei nie odpowiada specyfice usługi LDAP, która preferuje rzadkie zmiany. Zasoby fizyczne, o których chcielibyśmy przechowywać informację, to węzły sieci, znajdujące się wewnątrz nich szafy typu rack i stopień ich wykorzystania, dostępna moc elektryczna, urządzenia sieciowe, kable i włókna światłowodowe, patchpanele oraz typy złącz.

2.3 Kontakt systemu z użytkownikiem

System adresowany jest przede wszystkim do administratorów urządzeń sieciowych. Aby w maksymalnym stopniu uprościć korzystanie z systemu proponuje się obsługę systemu poprzez interfejs www. Taki sposób, oprócz niewątpliwych zalet, ma także pewne ograniczenia. Każda zmiana schematu bazy LDAP wymaga wprowadzenia zmian w kodzie implementacji interfejsu zmniejszając elastyczność całości systemu na modyfikacje struktur danych.

Większość zasobów sieci komputerowej, tj. urządzenia, patchcord-y, patchpanel-e, szafy typu rack powiązane są z konkretnym węzłem, dlatego też korzystanie z systemu w celu wprowadzenia, wyszukania czy też modyfikacji informacji rozpoczynać się będzie od wyboru węzła, z którym informacja jest związana.

Zasobem nie powiązanym z węzłami są dane dotyczące sposobu kontaktu z dostawcami sprzętu czy też pracownikami serwisów. Projekt uwzględnia możliwość gromadzenia i współdzielenia także i tej informacji.

Wobec braku istniejących rozwiązań, a co za tym idzie - doświadczenia związanego z elektronicznym repozytorium danych na temat zasobów sieci, przewiduje się, że sposób korzystania z systemu może ulegać modyfikacjom by korzystanie z niego było jak najbardziej intuicyjne a odnalezienie potrzebnej informacji maksymalnie proste i szybkie.

3 Projekt

Projekt zakłada utworzenie schematu bazy LDAP-owej (atrybuty i klasy obiektów oraz postać bazy katalogowej) jako repozytorium danych o zasobach POL-34/NASK.

Podstawowym zasobem sieci są węzły, dlatego występują one na najwyższym poziomie w hierarchii. Wszystkie pozostałe zasoby powiązane są z węzłami. Wyjątkami od tej reguły są kable światłowodowe (powiązane z dwoma węzłami) oraz dane kontaktowe do producentów, firm usługowych czy pracowników, którzy mogą być odpowiedzialni za pojedyncze urządzenie sieciowe, cały węzeł, kilka węzłów czy też wiele urządzeń rozmieszczonych w różnych węzłach. Taka struktura informacji. którą chcemy gromadzić, prowadzi do powstania zamieszczonego poniżej drzewa danych w bazie LDAP:

Drzewo dn: dc=pionier,dc=pl

dc=pionier,dc=pl

+---- ou=Locations [klasa organizationalUnit]

+---- ou=Cables [klasa organizationalUnit]

+---- ou=Other [klasa organizationalUnit]

Kolejne po lokalizacji poziomy hierarchii to szafa typu rack, a w szafie urządzenie lub patchpanel. Patchpanel składa się ze złączy światłowodowych, a urządzenie posiada karty, na których zlokalizowane są interfejsy. Interfejsy urządzeń i złącza na patchpanelach połączone są patchcordami, choć patchcordy mogą także łączyć ze sobą interfejsy dwóch urządzeń lub dwa włókna zakończone na patchpanelu.

Ze względu na możliwość łączenia za pomocą patchcord-u urządzeń i/lub patchpanel-i należących do różnych szaf, patchcord-y powinny być w hierarchii na tym samym poziomie, co szafy.

Także urządzenia powinny być na tym samym poziomie, co szafy. Wydajne urządzenia sieciowe szerokopasmowej sieci szkieletowej są dość pokaźnych rozmiarów, co może decydować o ustawieniu ich poza szafą. Patchpanel-e, ze względu na typ konstrukcji również mogą być do montażu w szafie typu rack lub jako samodzielne szafy do montażu na ścianie.

Przy planowaniu rozbudowy infrastruktury sieciowej węzła o elementy aktywne informacją równie ważną, jak dostępność odpowiednich patchcord-ów i złączy, jest dostęp do źródła zasilania o wymaganej mocy elektrycznej. Dlatego też bardzo istotną informacją związaną z węzłem są dane na temat skrzynki bezpiecznikowej i znajdujących się w niej bezpiecznikach.

Po uwzględnieniu wszystkich wymienionych powyżej wymagań drzewo danych bazy LDAP do przechowywania i gromadzenia danych dotyczących węzła przyjmuje postać jak poniżej. W drzewie danych wykorzystano klasy standardowe (organizationalUnit, inetOrgPerson) oraz klasy opracowane na potrzeby niniejszego projektu. Klasy zdefiniowane na potrzeby tego projektu posiadają prefiks pionier. Klasa inetOrgPerson zdefiniowaną w dokumencie RFC2798 "Definition of the inetOrgPerson LDAP Object Class" służy do przechowywania informacji o osobach. Według przyjętych reguł nazewnictwa nazwy formalne tworzone są na podstawie polskich wyrazów, natomiast nazwy klas obiektów w schemacie bazy LDAP z wyrazów angielskojęzycznych poprzedzonych prefiksem.

Poddrzewo dn: ou=Locations,dc=pionier,dc=pl

dc=pionier,dc=pl

+---- ou=Locations [klasa organizationalUnit]

+---- cn=L_1 [klasa pionierLocation]

| |

| +---- ou=Racks [klasa organizationalUnit]

| | |

| | +---- cn=Rack_1 [klasa pionierRack]

| | |

| | +----

| | |

| | +---- cn=Rack_n

| +---- ou=Devices [klasa organizationalUnit]

| | |

| | +---- cn=Device_1 [klasa pionierDevice]

| | | |

| | | +---- cn=Card_1 [klasa pionierCard]

| | | | |

| | | | +---- ou=GBIC [klasa organizationalUnit]

| | | | | |

| | | | | +----

| | | | | |

| | | | |

| | | | +---- ou=Interface [klasa organizationalUnit]

| | | | |

| | | | +---- cn=Interface_1

| | | | +----

| | | | |

| | | | +---- cn=Interface_n

| | | +----

| | | |

| | | +---- cn=Card_n

| | |

| | +----

| | |

| | +---- cn=Device_n

| +---- ou=Patchcords [klasa organizationalUnit]

| | |

| | +---- cn=Patchcord_1 [klasa pionierPatchcord]

| | |

| | +----

| | |

| | +---- cn=Patchcord_n

| +---- ou=Patchpanels [klasa organizationalUnit]

| | |

| | +---- cn=Patchpanel_1 [klasa pionierPatchpanel]

| | | |

| | | +---- cn=Connector_1 [klasa pionierConnector]

| | | |

| | | +----

| | | |

| | | +---- cn=Connector_n

| | +----

| | |

| | +---- cn=Patchpanel_n

| +---- ou=FuseBox [klasa organizationalUnit]

| |

| +---- cn=FuseBox_1 [klasa pionierFuseBox]

| | |

| | +---- cn=Fuse_1 [klasa pionierFuse]

| | |

| | +----

| | |

| | +---- cn=Fuse_n

| +----

| |

| +---- cn=FuseBox_n

+----

+---- cn=L_n

Warto tutaj nadmienić, że oprócz powiązań wynikających z położenia obiektów w strukturze hierarchicznej, istnieją zależnościP. Zależności te są implementowane poprzez dodanie do obiektu atrybutu wskazującego na inny obiekt. W ten sposób przechowywana jest informacja o producencie urządzenia, osobie kontaktowej, przynależności urządzenia do szafy oraz bezpiecznika, poprzez który jest ono zasilane. Na tej samej zasadzie pamiętana jest informacja dotycząca dołączenia patchcordu do konkretnego interfejsu urządzenia lub złącza na patchpanel-u.

Poniżej zamieszczony został schemat bazy LDAP, czyli tabelaryczne zestawienie atrybutów poszczególnych obiektów.

Obiekt LOKALIZACJA - klasa pionierLocation

NAZWA ATRYBUTU	TYP	ZNACZENIE
ou	String	nazwa wyróżniona
l	String	nazwa lokalizacji
postalAddress	String	adres
description	String	opis
pionierPriority	String	priorytet

Ze względu na dużą liczbę węzłów sieci, celem ułatwienia nawigacji pomiędzy węzłami, proponuje się wprowadzenie atrybutu priorytet. Wartość tego atrybutu będzie definiowana przez użytkownika, ale zalecane jest uzależnić ją od obecności w węźle urządzeń pracujących w danej warstwie sieciowej.

Obiekt SZAFA - pionierRack

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierDimension	String	wymiar (U)
pionierPhysicalDimension	String	wymiar fizyczny szafy
description	String	opis
jpegPhoto	Binary	zdjęcie

Obiekt URZĄDZENIE - pionierDevice

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierDevicePower	String	zasilanie
pionierProducerLink	DN	PRODUCENT
pionierSerialNumber	String	numer seryjny
pionierType	String	typ
description	String	opis
jpegPhoto	Binary	zdjęcie
pionierContactLink	DN	KONTAKT
pionierDeviceCommunity	String	community
pionierDeviceIMax	String	pobór prądu
pionierDeviceIPAddress	String	IP adres
pionierDeviceLogin	String	login
pionierDimension	String	wymiar
pionierFuseLink	DN	BEZPIECZNIK
pionierPositionLink	DN	SZAFA
pionierRackPosition	String	miejsce w szafie
pionierSoftware	String	oprogramowanie

Obiekt KARTA - klasa pionierCard

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierSerialNumber	String	numer seryjny
pionierType	String	typ
description	String	opis
jpegPhoto	Binary	zdjęcie

Obiekt GBIC - klasa pionierGBIC

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierMedia	String	medium
pionierSerialNumber	String	numer seryjny
pionierType	String	typ złącza
description	String	opis
pionierConnectionLink1	DN	PATCHCORD \|\| WŁÓKNO
pionierLayer2Address	String	adres drugiej warstwy

Obiekt INTERFEJS - klasa pionierInterface

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierInterfaceSpeed	String	prędkość
pionierInterfaceTechnology	String	technologia
pionierMedia	String	medium
pionierType	String	typ złącza
description	String	opis
pionierConnectionLink1	DN	PATCHCORD \|\| WŁÓKNO

Obiekt PATCHCORD - klasa pionierPatchcord

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierLength	String	długość
pionierType	String	typ włókna
description	String	opis
pionierConnectionLink1	DN	INTERFEJS \|\| GBIC \|\| ZŁĄCZE
pionierConnectionLink2	DN	INTERFEJS \|\| GBIC \|\| ZŁĄCZE

Obiekt PATCHPANEL - klasa pionierPatchpanel

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierPatchpanelConnNumber	String	liczba złącz
description	String	opis
jpegPhoto	Binary	zdjęcie
pionierDimension	String	wymiar
pionierPositionLink	DN	SZAFA
pionierRackPosition	String	miejsce w szafie

Obiekt ZŁĄCZE - pionierConnector

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierConnectorNumber	String	numer
pionierType	String	typ złącza
description	String	opis
pionierConnectionLink1	DN	PATCHCORD \|\| WŁÓKNO

Obiekt SKRZYNKA_BEZPIECZNIKOWA - klasa pionierFuseBox

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
description	String	opis
jpegPhoto	Binary	zdjęcie

Obiekt BEZPIECZNIK - klasa pionierFuse

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierFuseCurrent	String	prąd
pionierFuseVoltage	String	napięcie
pionierType	String	typ
description	String	opis

Struktura danych opisująca kable i włókna światłowodowe jest znacznie prostsza. Kabel światłowodowy składa się z włókien co przedstawiamy poprzez umiejscowienie obiektów włókien poniżej obiektu opisującego kabel w drzewie danych. W projekcie tym poprzez kabel światłowodowy rozumiany jest jego odcinek pomiędzy dwoma węzłami, nawet jeżeli w węźle znajduje się tylko przełącznica, tj. patchpanel z patchcord-ami.

Poddrzewo dn: ou=Cables,dc=pionier,dc=pl

dc=pionier,dc=pl

+---- ou=Cables [klasa organizationalUnit]

+---- cn=Cable_1 [klasa pionierCable]

| |

| +---- cn=Fiber_1 [klasa pionierFibre]

| |

| +----

| |-

| +---- cn=Fiber_n

+----

+---- cn=Cable_n

Obiekt KABEL_ŚWIATŁOWODOWY - klasa pionierCable

NAZWA	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierLength	String	długość
pionierType	String	typ
description	String	opis
pionierConnectionLink1	DN	link na obiekt LOKALIZACJA
pionierConnectionLink2	DN	link na obiekt LOKALIZACJA

Obiekt WŁÓKNO - klasa pionierFibre

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
pionierFibreNumber	String	numer
pionierType	String	typ włókna
description	String	opis
pionierFibreAttennation	String	tłumienność
pionierConnectionLink1	DN	INTERFEJS \|\| GBIC \|\| ZŁĄCZE \|\| WŁÓKNO
pionierConnectionLink2	DN	INTERFEJS \|\| GBIC \|\| ZŁĄCZE \|\| WŁÓKNO
pionierFibreCMD	String	dyspersja chromatyczna
pionierFibrePMD	String	dyspersja polaryzacyjna

System gromadzenia informacji o zasobach sieci POL-34/NASK powinien także umożliwiać składowanie informacji dotyczącej sposobu kontaktu z dostawcami sprzętu czy też pracownikami serwisów. Dane te znajdują się w trzeciej gałęzi i są powiązane z obiektami z pozostałych dwóch gałęzi poprzez wartości atrybutów wspomnianych obiektów.

W gałęzi Other, oprócz podkatalogu zawierającego obiekty opisujące dane osobowe, znajdują się podkatalogi ou=Producers i ou=Companies zawierające obiekty klasy pionierCompany. Katalog ou=Producers przewidziany jest do przechowywania danych o producentach sprzętu, podczas gdy katalog ou=Companies ma w zamierzeniu zawierać dane o firmach usługowych, tj. wynajmujących pomieszczenie na węzeł, dokonujących przeglądów serwisowych itp.

Poddrzewo dn: ou=Other,dc=pionier,dc=pl

dc=pionier,dc=pl

+---- ou=Other [klasa organizationalUnit]

+---- ou=Producers [klasa organizationalUnit]

| |

| +---- cn=Producer_1 [klasa pionierCompany]

| |

| +----

| |

| +---- cn=Producer_n

+---- ou=People [klasa organizationalUnit]

| |

| +---- uid=Person_1 [klasa inetOrgPerson]

| |

| +----

| |

| +---- uid=Person_n

+---- ou=Companies [klasa organizationalUnit]

+---- cn=Company_1 [klasa pionierCompany]

+----

+---- cn=Company_n

Obiekt FIRMA oraz PRODUCENT - klasa pionierCompany

NAZWA ATRYBUTU	TYP	ZNACZENIE
cn	String	nazwa
pionierName	String	nazwa w ramach PIONIER-a
mail	String	e-mail
pionierWWWAddress	String	strona www
postalAddress	String	adres
description	String	Opis

Obiekt OSOBA - klasa inetOrgPerson

NAZWA ATRYBUTU	TYP	ZNACZENIE
uid	String	identyfikator osoby
cn	String	imię + nazwisko
givenName	String	imię
sn	String	nazwisko
telephoneNumber	TelephoneNumber	numer telefonu
mail	String	e-mail
seeAlso	DN	link na obiekt FIRMA, PRODUCENT lub LOKALIZACJA

Drzewo i schemat danych zapisane w formalnej postaci akceptowanej przez serwer LDAP (implementacja iPlanet SunONE Directory Server) przyjmują następującą postać:

# PIONIER Schema

dn: cn=schema

# PIONIER Attributes

attributeTypes: ( pionierDeviceCommunity-oid NAME 'pionierDeviceCommunity'